As the reliability and availability of networks grow, more people and organizations become comfortable with performing computing tasks using functionality provided online. For example, many applications that would have previously been provided only as stand-alone or “shrink-wrapped” applications that ran locally on a particular computing device may now be accessed over a network using a web browser or other connected application or executable code. Such applications are often referred to as “online applications,” “web applications,” and the like. As just one of many examples, many people today use “web-based email” applications, such as “Hotmail,” provided by Microsoft Corporation of Redmond, Wash., or “Gmail,” provided by Google Corporation, of Mountain View, Calif. In such an application, for example, one or more “server” computing devices may hold user interface information, executable code, and data associated with the application, and provide such information to a web browser or other similar application. When a user submits a request—in one example using a web browser application and HTTP—the one or more servers may execute code and respond with the appropriate information. In a mail application, this information may include a user interface that displays and enables a user to interact with email.
While such online applications provide many desirable characteristics, they also have elements that are less preferable. One important characteristic of an application that is truly only accessible online is that such an application absolutely requires network connectivity: even if a user's computing device is otherwise operating normally, if the device can't connect over a network to the server or servers that provide the application, then the user can't use the application or access the desired data. Even though networks have continually become more ubiquitous, network connectivity may still be limited for a variety of reasons—in some geographic areas network connectivity may not be available at all and in areas that do have network connectivity, such connectivity may be slow, may enable only relatively small amounts of data to be exchanged, may be intermittently or not consistently available, or may have other limitations.
For these and other reasons, it may be desirable to provide access to such online or server-provided applications and data when a user or device is “offline.” That is, for example, it may be desirable to enable a user to access some or all of the functionality of an online application or some or all of the data associated with an online application when the user's device is offline or not connected to a network or to the server or servers providing the application.
There are a wide variety of ways in which such offline applications may be implemented. Generally, many methods transfer at least portions of application functionality and data from a server or servers to a client device when network connectivity is available. Such pre-transferred functionality and data is then used, in a variety of ways, if or when the device does not have network connectivity, when the quality of device's network connectivity is below a particular threshold, when the user or some other entity chooses to use the local functionality even when connectivity is available, or in other instances.
For example, in some implementations a user may install some set of software or executable instructions on a client device. Such software may then download or transfer at least particular parts of an application and store such parts locally on the client device. In some particular implementations, such software may install functionality that extends or uses “hooks” into a web browser application (or other application), so that when a user requests some part of a particular application—such as a particular HTML page associated with an application—the browser extension, or possibly “protocol handler” in this particular example, determines that the requested page is stored locally and provides the page without a request to a remote server. While such browser extensions may be somewhat more difficult to install—they may require elevated, administrative, or root permissions, for example, because they modify the operation of a browser in a way that may in some cases be considered “unsafe”—they also provide one way to provide at least some portions of an application when a device cannot connect to a remote server.
In the same or other implementations, additional software may perform other tasks useful as part of providing an application in an offline mode, including as part of accessing “dynamic data.” In at least some contexts, “dynamic data” may be defined to be data that may be different for different users, for different instances of a particular application, and so on. As a specific example, in an email application dynamic data may include the specific email messages associated with a particular user, the user's email address, and the like. (It should be noted that just because a part of an application is not “dynamic data,” as defined here, does not necessarily mean that that part of the application is entirely or completely static and will not ever change.) In some implementations, when a user makes a request to an application that accesses dynamic data or that changes dynamic data (including adding new data, updating existing data, and deleting existing data), the code in the application may first determine if the application is an online or offline. If the application is online, such a request may be dispatched to a remote server. Such operation may in many cases be the same as a typical online application with no offline functionality: when a user visits a particular web site to view their email, the requests for their email—the dynamic data—are transmitted to a remote server that in turn responds with new pages that include the requested email message or messages.
However, when an application is offline, application code itself (or code used or associated with the application) may determine that the application is offline and then attempt to access the dynamic data in a different way. For example, in some implementations, the code may test for online or offline status and when the application is offline may request data from or change data in a database that is located on the local device. While such an implementation may enable an application to be used when a device cannot connect to a remote server, it also may significantly increase the complexity of the application, which may in turn make the application more difficult or costly to develop, may make the application more susceptible to problems or “bugs,” and so on. For example, rather than always assuming that data can be accessed in one particular way, such an application may have to consider the case where data is accessed differently, using a remote or local store. Such an application also may need to manage, for example, the schema and data in the local database or data store, may need to determine when and how to synchronize the data in the local data store with a remote data store, and so on.